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switching mode, the headers include source routes specified 
in terms of local link identifiers used by routers in the 
network. Also, receiving routers are identified using local 
link identifiers associated with communication links 
between a transmitting router and an intended receiving 
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SYSTEM FOR ROUTING AND SWITCHING 
IN COMPUTER NETWORKS 

STATEMENT OF GOVERNMENT LICENSE 
RIGHTS 

The United States Government has a paid-up license in 
portions of this invention and the right in limited circum- 
stances to require the patent owner to license others on 
reasonable terms as provided for by the terms of Contract 
No.: DAAH01-98-C-R005, awarded by the U.S. Army Avia- 
tion & Missile Command. 

FIELD OF THE INVENTION 

The present invention relates to routing and switching 
protocols in computer networks, e.g., ad hoc networks, and 
may find particular application in such networks that utilize 
radio communication links and in which routers can have 
both hosts and networks attached to them. 

BACKGROUND 

Multi-hop packet-radio networks, or ad hoc networks, 
consist of mobile hosts interconnected by routers that can 
also move. The deployment of such routers is ad hoc and the 
topology of such networks is very dynamic, because of host 
and router mobility, signal loss and interference, and power 
outages. In addition, the channel bandwidth available in ad 
hoc networks is relatively limited compared to wired 
networks, and untethered routers may need to operate with 
battery-life constraints. In these networks, routing must 
preferably be accomplished using as few a number of 
control messages and neighbor-to-neighbor handshakes as 
possible, in order to conserve channel bandwidth for user 
data and preserve the battery life of untethered nodes. 
Because of the dynamics of the topology in an ad hoc 
network, broadcast radio links are preferable for intercon- 
necting routers without the need for topology planning. 

Presently, packet forwarding in computer networks is 
generally accomplished using one of three available tech- 
niques: bridging, routing, or switching. Bridge protocols 
permit bridges to forward packets in either of two ways. In 
one scheme, packets can specify a source route in terms of 
pairs of unique bridge and network identifiers from source to 
destination host. Alternatively, bridges may first establish a 
spanning tree of the network and then send packets over 
branches of such a tree that appear closer to the destination 
hosts. The forwarding table used by a bridge to forward 
packets over the spanning tree has an entry for only those 
destinations for which packets have been processed by the 
bridge. The attractive feature of spanning-tree bridges is that 
packet forwarding is very simple; however, the available 
network bandwidth is used inefficiently. Source-routing 
bridges make better use of the bandwidth available in the 
network, but require a source routing technique that involves 
the hosts. 

Routing protocols permit routers to forward packets either 
as datagrams or as part of virtual circuits. In both 
approaches, routers build and maintain a routing table speci- 
fying the next hop to each destination. In datagram routing, 
each packet specifies a source and a destination using 
addresses that are unique in the entire network or internet; a 
router forwards each datagram by looking up its routing 
table for the next hop on a preferred path to the destination. 

In contrast to datagram routing, with virtual circuit (VQ 
routing routers first establish a path from source to destina- 
tion using a signaling protocol, and then forward packets 
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along the established VCs using VC identifiers. The path 
taken by the VC is determined based on the information 
stored in the routing tables of the routers. Such a path is 
given a virtual circuit identifier and routers maintain a 

5 forwarding table listing the next hop of each VC traversing 
the router. Each packet specifies the VC of the packet, and 
routers along the VC consult their forwarding tables to 
forward those packets. A VC is torn down using a signaling 
protocol when the flow of packets ends. 

10 VCs can be specified with unique identifiers. In such 
cases, the origin of the VC assigns a number to the VC and 
the same number is used at every relay router along the VC; 
the VC number becomes unique together with the identifier 
of the VC origin. However, to reduce the size of VC 

15 identifiers, routers along the path of a VC can assign local 
identifiers to the VC. With this approach, each router along 
the path of the VC knows, for every VC local identifier in its 
forwarding table, the next router on the path of the VC and 
the VC local identifier used by the next node for this VC. A 

20 router in a VC swaps the VC local identifier in the header of 
an incoming packet into the VC local identifier expected by 
the next hop in the VC. The advantages of VC routing with 
local identifiers are: (a) routers use short identifiers to 
specify and lookup VCs in their forwarding tables, and (b) 

25 those short identifiers are used to index an entry in the 
forwarding table used to forward packets. Because local VC 
identifiers are short and have fixed length, and because an 
exact match algorithm is used to forward packets, VC 
routing with local VC identifiers can be easily implemented 

30 in hardware. This approach to packet switching has been 
called label swapping or label switching in recent literature. 
See, e.g., B. Davie, P. Doolan, and Y. Rekhter, Switching in 
IP Networks, Morgan Kaufmann (1998). 
Although approaches based on label swapping have 

35 received much attention lately, the basic label swapping 
mechanism and mechanisms to set up states at routers so that 
they can carry out packet forwarding based on label swap- 
ping have been proposed and implemented many times in 
the past since the mid 1970s. VC routing with local identi- 

40 flers has been studied by Segall (A. Segall and J. Jaffe, 
"Route Setup with Local Identifiers," IEEE Trans. Commun. 
Vol. COM-34, No. 1, January 1986, pp. 45-53), and packet 
switching based on label swapping has been called ID 
swapping (G. Markowsky and F. H. Moss, "An Evaluation 

45 of Local Path ID Swapping in Computer Networks," IEEE 
Trans. Commun. Vol. COM-29, March 1981, pp. 329-336), 
path number and logical record number (M. Schwartz and T. 
Stern, "Routing Protocols," IEEE Trans. Commun. Vol. 
COM-28, April 1980). One of the first proposals and imple- 

50 mentations of label swapping was the logical record number 
used by TYMNET in the late 1970s. Id. 

Recent proposals for packet switching include: Internet 
Protocol (IP) switching (P. newman, T. Lyon, and G. 
Minshall, "Flow labeled IP: A connectionless Approach to 

55 ATM," Proc. IEEE Infocom 96, San Francisco, Calif., 
1996), tag switching (Y. Rekhter et al., "Tag Switching 
Architecture Overview," Proc. IEEE, Vol. 85, No. 12, 
December 1997), MPLS as being developed by the Internet 
Engineering Task Force, IBM's ARIS, and Toshiba's cell 

60 switching router. All these approaches apply label swapping 
to bypass the network-level lookup of routing tables. 

In the IP switching approach, IP switches, which are 
routers implementing the IP switching approach to packet 
forwarding, must implement a routing protocol to establish 

65 a routing table and packets are first routed using their 
network addresses. When packets for the same flow start 
traversing a given IP switch s, that IP switch can assign a 
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local VC identifier to the packet flow and instruct the state setup packets is to simply decrement a time-to-live 
previous-hop IP switch to use that VC identifier in all field in the packet header to allow the packet to visit a 
packets it forwards to s for that flow. In the same way, the maximum number of hops trying to set up state. Loop 
next-hop IP switch can instruct s to use a local VC identifier detection is still an open issue under discussion for MPLS, 
defined by the next hop in all packets of the flow forwarded 5 ^ differences the labe i swapping or label switch- 
by s to the next-hop IP switch When that happens, IP switch . ^ to ^ lie m lhe ^ for which a 
s can bypass its jrouting-table lookups for packets in the flow established at the routers (e.g., destination 

T d^endfie^ PPmg UC f0 0riented ' Wrtual drcuitS ' etC > aDd the mechanisms 

oc L 1 . . r ,. j in the protocols used to set up the label-swapping state at the 

Tag switching consists iof a forwarding component and a 10 routeret ^ distribution of labe i^in d ing information among 

control component, similar to the VC rouUng with local ^ me caQ be characterized m ^ 

identifiers scheme. A tag switch is a router capable of piggybacking the distribution on top of routing 

performing the tag switching mechanism. An entry m the ^ ~ ^ a ate tocol for la5el distr i bution . 

forwarding table (called a tag forwarding information base ^ ^ used ^ me aboye }abel swit o _ 

or TFIB) consists of an incommg tag (equivalent to a VC 15 ^ {Q ^ destinalions or ^ociaUons between 

local identifier) and one or more sub-entries for the tag ^ destinations> the routing protocols that can be 

specifying the outgoing tag, interface and hnk-level mfor- ^ for ^ dissemmation of such in f ormat io D are distance- 

mation. The link-level information maintained in the TFIB of th . vector oriented To datC) routing protocols 

consists primarily of the medium access control (MAC) ba$ed Qn link . state information (e . g ., OSPF) have been 

address of the next horUf a switch receives a packet whose 20 considered tQ ^ choices for distributing label-binding 

tag equals a tag in its TFIB, it swaps the MAC address and mformatiorii B Davie , P. Doolan, and Y. Rekhter, Switching 

label in the incoming packet with the MAC address and kbel ^ Ip NetWQrks M K aufmann, 1998. 

specified in its TFIB and sends the packet over the interface . . . , • * ^ a * c 

i 'c j * «u tt7it> Source routing has also been implemented and used tor 

also specified in the 1F1B. , & , ...... ^ . , 

™ , . . ft + u ^ w n p routers, and can be considered a hybrid between datagram 

The control component of tag switchmg consists or the 2 s . . . . , • » • „ 7 u . J v . _ 

F . . . 6 . c # u u * ,1' routing and label switchmg. With source routing applied to 

advertisement among neighbor switches ot the binding ... r i . a ,l * 

Z i. u c a *' * * a*u • • . ■* routers, the header of a packet specifies the source route 

between the address of a destination and the incoming tag it . ! ** F r , t u a 

™. . , . f . « * consisting of the entire path from source to destination; the 

uses for the destination. This can be done with a separate tag & . .„ J T. . . 

... ^ , /rmm . . , tU * <. „~Ja source route is specified m prior routing schemes using the 

dBtr.bm.on protocol (TOP) or by mcludmg the tag ass.gned addresses of the routers in the path to the destination, 

to a dest.nat.on as an attachment to the updates sent by the 30 A ^.^^ example of mis appr J ch * the ^ rollte 

routing protocol used in the network. Once a switch assigns . r rr 

an incoming tag to a destination, it can establish an entry in op ion in . 

its TFIB when it receives the tag-lo-destination binding from The source route can be obtained by the source of the 

the neighbor that it chooses as the next hop to the destina- P"*et in two ways. The router can compute the source route 

tion J5 locally if it knows the entire network topology; alternatively, 

All of the above label switching schemes and derivatives a . P ath P acket can be sem '° the destina : 
thereof share certain common features: For example, in each turn to gather the source route and the destination i can send 
of these schemes, a single incoming label (called a VC local a ^ back to tne *«>** wltb .' he source route - All «BUng 
identifier, path number, or tag, for example) is associated source routing proposals specify source routes in terms of 
with a single outgoing label for purposes of the label « the nodes alon S ,he P ath from sou,ce t0 destinat.on. 
swapping needed to switch packets towards a given desti- SUMMARY OF THE INVENTION 
nation or for a given VC. Also, the labels refer to destina- 
tions or associations between a source and a destination. The In one embodiment, a protocol for a computer network in 
mapping established at a node between a destination (or VC) which routing operation codes (ROCs) in headers of packets 
and an incoming label (called a VC local identifier, path 45 transmitted within the network specify to a receiving router 
number, or tag, for example) is disseminated among neigh- which of a number of routing or switching methods to apply 
bor nodes by means of explicit exchanges of control infor- to forward associated packets. The packets may be for- 
mation. This signaling is carried out in addition to the warded in any of the following modes: (a) a broadcast mode, 
signaling required to maintain routing tables based on des- (b) a hop-by-hop mode based on receiving node address 
tination addresses. Further, the unique addresses of both the 50 information, (c) a label swapping mode, (d) a source- 
sending and receiving nodes are specified in the headers of switching mode, (e) a flow switching mode, or (f) a hop- 
the packets being forwarded by means of label swapping. by-hop mode based on sending mode address information. 
This information is used to ensure that only the receiving In the broadcast mode, packets transmitted by a first 
node addressed in the packet accepts the packet and asso- router are accepted by all neighboring routers of the first 
ciates the label in the packet with the correct outgoing label. 55 router. In the hop-by-hop mode based on receiving node 

Furthermore, the descriptions of tag switching and IP address information, packets are accepted by the receiving 

switching assume the existence of a loop detection mecha- router if the receiving node address information matches the 

nism when switches establish their label-to-destination map- receiving router's media access control address. In the label 

pings. A loop consists of the forwarding along a loop of swapping mode, packets are accepted by the receiving router 
packets that set up label-swapping states in the routers, until 60 if the packets include a media access control address of the 

an external action is taken, such as exhausting a "time to receiving router, and packets are forwarded from the receiv- 

live" for the packet. The loop detection mechanism adopted ing router according to a switching table indexed by a media 

in these prior schemes consists of using a path vector in the access control address of a transmitting router. In the source 

header of packets that establishes the binding between the switching mode, the headers include source routes specified 
labels used to forward traffic. The path vector in a stale setup 65 in terms of local fink identifiers used by routers in the 

packet specifies the routers that have been visited by the network. In the flow switching mode, receiving routers are 

packet. Another technique used to cope with the looping of identified using local link identifiers associated with com- 
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municatioa links between a transmitting router and an 
intended receiving router, which along with the local link 
identifier is used as a criterion upon which a receiving router 
accepts or rejects aj)acket__ 

TheAo<&\^T^Adtnffitr$:miy-bG-ob\ained using either a 
flood-searfch'meltn^dor through a routing protocol operating 
within the network. In the source switching mode the 
receiving router forwards a received packet according to a 
local link identifier specified in a source route portion of an 
associated header. 

In the flow switching node, flow states at routers of the 
network are established according to information in data 
packets transmitted within the network. The information 
included in the data packets allows for bindings between 
incoming and outgoing flow labels to be established at each 
of the routers. Such information may include a flow label 
and a source route to a destination node in the network. 

In a further embodiment, forwarding a packet from a first 
router of a computer network to a second router thereof is 
achieved according to a routing operation code specified in 
a header of the packet. The routing operation code may 
specify any of the above modes and the value thereof 
determines what other types of information are included in 
the header of the packet. In some cases, the sending node 
address information (e.g., its MAC address) is included in 
the header of the packet. Also included may be the receiving 
node address information (e.g., MAC address), receiving 
node — assigned local link identifier, flow label and/or source 
route. 

In the source switching mode, amending node obtains a 
source route to an intended destmation:tfsing eithejLoJ.a-flood 
search process or a routing protocol operative-witbin the 
computer network. In the source switching mode, the packet 
is forwarded from the first router by reading a source route 
specified in the header and substituting a transmitting router 
local link identifier and if present, a receiving router local 
link identifier, included in the header with corresponding 
values needed by the second router. In the flow switching 
mode, the packet is forwarded from the first router by 
reading a source route specified in the header and substitut- 
ing a flow label included in the header with a corresponding 
value needed by the second router. 

In some cases, the packet is a data packet that includes 
flow setup instructions for the second router. In such cases, 
the packet's header includes a MAC address of the first 
router and a local link identifier assigned by the first router 
and may also include a flow label and a source route or a 
flow label and a path traversed field. 

In yet another embodiment, a packet header includes a 
routing operation code configured to indicate to a receiving 
router which of a variety of routing and/or switching meth- 
ods to apply in forwarding an associated packet. Such 
routing and/or switching methods may be any of: (a) a 
broadcast mode, (b) a hop-by-hop mode based on address 
information regarding the receiving router, (c) a label swap- 
ping mode, (d) a source switching mode, (e) a flow switch- 
ing mode, and (e) a hop-by-hop mode based on address 
information regarding a transmitting router. The routing 
operation code generally determines which of the following 
fields of information are included in packet header: (a) 
address information of the receiving router, (b) local link 
identifier information assigned by: (i) a transmitting router 
and/or (ii) the receiving router, (c) a flow label, (d) a source 
route, (e) a path traversed, and (f) a payload type. 

Another embodiment provides a router having a neighbor 
identification table configured to allow the router to deter- 
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mine whether a received packet should be accepted and, if 
so, which of a number of switching tables to access to 
retrieve information for forwarding the packet within a 
computer network. The switching tables may include a 
source switching table, configured to provide packet for- 
warding information which the router is to use to forward the 
packet using a source switching process, and/or a flow 
switching table, configured to provide packet forwarding 
information when the router is to forward the packet using 
a flow switching process. 

The neighbor identification table is arranged so as to be 
indexed using local link identifiers assigned by neighboring 
routers to links communicatively coupling the router thereto 
and/or to provide pointers to source switching and/or flow 
switching tables. The source switching table is arranged so 
as to be indexed according to local link identifiers assigned 
by neighboring routers to finks communicatively coupling 
the router thereto. The flow switching table specifies map- 
pings from incoming flows to outgoing flows, local link 
identifiers for next hops and associated link-level informa- 
tion. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention is illustrated by way of example, 
and not limitation, in the figures of the accompanying 
drawings in which like reference numerals refer to similar 
elements and in which: 

FIG. 1 illustrates an example of an ad hoc wireless 
network with routers configured in accordance with the 
present routing protocol; 

FIG. 2 illustrates an example of a packet header for 
transporting routing and switching information in accor- 
dance with an embodiment of the present invention; 

FIG. 3 illustrates an example of a router configured with 
switching tables in accordance with an embodiment of the 
present scheme; 

FIG. 4 illustrates an example of a neighbor identification 
table configured in accordance with an embodiment of the 
present scheme; 

FIG. 5 presents an example of local link identifiers 
assigned by routers of an ad hoc network; 

FIG. 6 illustrates an example of a neighbor identification 
table for one of the routers of the network shown in FIG. 5; 

FIG. 7 illustrates an example of a source switching table 
for one of the routers of the network shown in FIG. 5; 

FIG. 8 illustrates an example of a flow switching table for 
one of the routers of the network shown in FIG. 5; 

FIG. 9 illustrates another example of a neighbor infor- 
mation table for a router of the network shown in FIG. 5; 

FIG. 10 illustrates another example of a source switching 
table for one of the routers of the network shown in FIG. 5; 
and 

FIG. 11 illustrates another example of a flow switching 
table for one of the routers of the network shown in FIG. 5. 

DETAILED DESCRIPTION 

A scheme for integrating routing and switching in com- 
puter networks is disclosed herein. Although discussed with 
reference to certain illustrated embodiments, upon review of 
this specification, those of ordinary skill in the art will 
recognize that the present scheme may find application in a 
variety of systems. Therefore, in the following description 
the illustrated embodiments should be regarded as exem- 
plary only and should not be deemed to be limiting in scope. 



07/23/2004, EAST Version: 1.4.1 



US 6,6! 

7 

The present scheme enables multiple routing and switch- 
ing methods in the same network. Each packet being routed 
includes a routing operation code (ROC) instructing the 
receiving router which routing or switching method to apply 
to forward the packet. A packet can be forwarded in any of 
the following forwarding modes: 

(a) a basic broadcast mode, in which the packet sent by a 
router is accepted by all its neighbors; 

(b) a conventional hop-by-hop mode, in which the packet 
is accepted by a router based on the receiver MAC 
address specified in the packet header and then passed 
to a higher layer for further processing; 

(c) a conventional label-swapping mode, which uses the 
unique MAC address of the receiver specified in the 
packet to decide whether to accept a packet or not, and 
uses the unique MAC address of the sender and a flow 
label to forward an accepted packet according to a 
switching table; 

(d) a source-switching mode, in which the entire source 
route is specified in the packet using local link identi- 
fiers instead of the unique addresses of relay routers as 
is common in previous source routing approaches. This 
use of local link identifiers is further explored in 
co-pending application Sen No. 09/418,700 entitled 
"System for Communicating Labeled Routing Trees to 
Establish Preferred Paths and Source Routes with Local 
Identifiers in Wireless Computer Networks", filed Oct. 
15, 1999, assigned to the Assignee of the present 
invention and incorporated herein by reference; 

(e) a flow-switching mode, which differs from conven- 
tional switching methods based on label swapping in 
that only the unique MAC address of the sender of the 
packet is used and the receiver is identified by means of 
local link identifiers associated with the fink between 
the sender and the intended receiver of the packet (see 
the above-cited co-pending application for further 
details); or 

(f) a basic incremental (hop-by-hop) mode, in which the 
packet is accepted by a router based on the unique 
MAC address of the sender and one of multiple local 
link identifiers specified in the packet header. The 
packet is then passed to a higher layer for further 
processing and routing. 

The various forwarding modes are enabled by a flow switch- 
ing protocol. 

In the first three of the above forwarding modes, packets 
are accepted based entirely on the MAC addresses of the 
sender and receiver nodes carried in the packet header. 
However, in the latter three forwarding modes, packets are 
accepted based on local link identifiers carried in the packet 
header. The local link identifiers assigned by the router to 
links with its neighbors and those assigned by the router's 
neighbors to links with the router can be obtained by the 
flow switching protocol through a channel access protocol, 
such as the one proposed in co-pending application Ser. No. 
09/248,738, entitled "Adaptive Communication Protocol for 
Wireless Networks", filed Feb. 10, 1999, assigned to the 
Assignee of the present invention and incorporated herein by 
reference. 

This flow switching protocol obtains source routes to 
destinations in one of two ways: (a) on demand, in which 
case search messages are sent out to obtain the source routes, 
or (b) by working in combination with a routing protocol 
that can provide source routes. These source routes are 
specified in terms of transmitter-assigned local link identi- 
fiers (LLIDs) given to the links along the path from the 
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source router to the destination. In addition to saving com- 
munication bandwidth, using LLIDs permits the forwarding 
of packets with such source routes to be done using a direct 
index into a forwarding table, which can be easily done in 
5 hardware. 

Tjhjj^^tr ^^swjtchin by packet 

heaaeS?pecifyingTs^^ address of 

the router that originated the packet and a sequence of 
LLIDs specifying the path to a destination, and by routers 

10 maintaining a table of all LLIDs assigned to the router by its 
neighbors. When a router receives a packet specifying 
source switching, the router accepts the packet based on the 
LLIDs specified for the next hop of the packet, and forwards 
the packet to the neighbor router indicated by the match 

is between the LUD of the next hop specified in the source 
route and the LLIDs the router assigned to the finks with its 
neighbors. 

The flow switching mode is implemented by routers 
maintaining a switching table similar to that used in label 

20 switching. Routers can use either incremental or source- 
switching flow establishment, which processes are described 
below. Both approaches use data packets to establish the 
flow state and the result of sending the flow establishment 
data packet is the establishment of the binding between 

25 incoming and outgoing flow labels at each router in the path 
from source to destination. A packet intended for a flow that 
is already established specifies the flow switching mode in 
the ROC of the packet, the flow label assigned by the 
sending node, the address of the sending node, and the 

30 LLIDs assigned to the link in use by the sending and 
receiving node. An entry in the flow-switching table is 
erased either after a timeout or the processing of a packet 
with an ROC with a flow-termination code. 

The flow state needed to carry out flow switching is 

35 established at routers by either flow establishment using 
source switching, or incremental flow establishment. With 
flow establishment by source switching, the source of a 
packet stream or flow assigns a flow label to the flow and 
sends a first packet with a source route to the destination of 

40 the flow, the flow label for the flow, and an ROC instructing 
the relay routers to use source switching to forward the 
packet and to establish an entry in their flow switching tables 
for the flow as well. A relay router that receives the packet 
assigns a flow label to the flow, makes an entry in its 

45 flow-switching table with the mapping of the incoming and 
the outgoing flow labels and the associated neighbors along 
the path for the flow, and relays the packet with the same 
ROC, the new flow label, the source route, and an index to 
the source route pointing to the next-hop router as the first 

50 non-traversed hop of the source route. 

With incremental (or hop-by-hop) flow establishment, the 
source and each relay router in the path from the source to 
the destination of the flow decides how the packet should be 
forwarded. The ROC of the packet specifies hop-by-hop 

55 flow establishment, which instructs the router to look up its 
routing table to determine the next hop, and to establish the 
binding between incoming and outgoing flow labels. The 
header of the flow-establishment data packet carries a path 
vector specifying the source and the LLIDs of the routers 

60 visited by the flow-establishment data packet. In one 
embodiment of the present scheme, source-switched flow 
establishment is adopted because the amount of information 
in the headers of flow-establishment packets is the same and 
the processing of packets in source switching mode is much 

65 faster than in hop-by-hop routing. 

As in prior schemes, a router can assign a flow label to a 
packet flow in many different ways. One approach consists 
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of using the same flow label for any flow intended for the can receive and acknowledge packets from the other IR, e.g., 

same destination and the same type of service. Although IR 16h. Accordingly, a physical broadcast link connecting 

many variations of packet switching based on label swap- multiple IRs is mapped into multiple point-to-point bidirec- 

ping and source routing have been implemented in the art, tional links defined for the same IRs. Each pair of adjacent 

the present scheme is unique in a number of ways, including: 5 IRs defines two point-to-point bidirectional links between 

(a) It obtains local link identifiers of all the links needed ^em, one m each direction. Each point-to-point bidirec- 

to route or switch packets on a hop-by-hop or source l i° nal lmk has a head node of the Unk ™ 6 a tail node of the 

route basis. ^ n * c * 

/L v Ti . i * . * ■ i t ' c * *j *-r *u * « As indicated above, the flow switching protocol for use in 

(b) It uses local link identifiers to identify the next router , , , * A • ^ £ 

to process the packet, which makes more efficient use 10 ad hoc network 10 »"«»">■"* wth pn^nt mvenUon 

ofbandwidthwhilestiUenablingthepacketfomarding "W"? 5 a vanety of packet forwarding modes. This flow 

niui ;*ui ■ switching protocol obtains source routes to destination on 

based on now labels or source routes to be done m . , & r . .„ , . c 

, j demand, where source routes are specified in terms of 

transmitter- assigned LLIDs regarding the links along the 

(c) It switches packets from source to destination without J$ pflth from the rQUter tQ me destinatioD) or works m 

the possibility of looping by specifying the LLIDs combinati on with a routing protocol capable of obtaining 

along the path in the packet headers, and enables this such f0Utes ^ flow Aching protocol then ^ 

type of switching to be done in hardware. LLIDs to support the various packet forwarding modes. If 

(d) It can switch packets based on label swapping such the flow switching protocol is used in combination with a 
that: 20 routing protocol that can provide source routes to destina- 

(i) The mapping between flow labels and neighbor tions expressed in terms of the LLIDs of the links traversed 
nodes is established on demand (i.e., not for every in those routes, the flow switching protocol does not incur 
destination or flow). more traffic than that needed for the transfer of data packets 

(ii) Data packets are used to set up flows, and there is themselves. In addition, the use of LUDs in the forwarding 
no separate signaling protocol needed other than the 2 s modes of the flow switching protocol enables the imple- 
routing instructions in the headers of the packets. mentation of all its packet forwarding functions in hardware. 

(iii) There is no looping of data packets used to set up Deriving Source Routes with Local Link Identifiers 
flows. The flow switching protocol can be imple- i n one embodiment, the present scheme works in combi- 
mented at the link layer or below. It can be used to nation with a routing protocol that incorporates local link 
encapsulate IP packets directly, or to encapsulate 30 identifiers (LLIDs) as part of the routing information 
MAC packets. exchanged among routers. Such a routing protocol can be 

(e) It can switch packets from one router to one or the Adaptive Internet Routing (AIR) protocol described in 
multiple neighbors by specifying such neighbors using co-pending application Ser. No. 09/418,700, entitled. "Sys- 
one or multiple local link identifiers. tem for Communicating Labeled Routing Trees to Establish 

The present scheme is well suited for wireless and wired 35 Preferred Paths and Source Routes with Local Identifiers in 

networks and the IP internet, in which routers are intercon- Wireless Computer Networks", in which routers communi- 

nected by point-to-point or broadcast links (e.g., local area cate labeled routing trees (LRTs). A link from node x to node 

networks) to one another. The present invention is also well y in an LRT is given a local link identifier (LLID) by x, the 

suited for an ad hoc network that provides a seamless head of link (x,y). A second example of a routing protocol 

extension of the IP Internet to the ad hoc wireless environ- 40 that can be used in combination with the present scheme is 

ment. FIG. 1 illustrates aspects of an exemplary ad hoc a modification of a topology-broadcast protocol (e.g., OSPF 

internet. J. Moy, "OSPF Version 2," RFC 1583, Network Working 

Ad hoc network 10 may be considered as a number of Group, March 1994) in which each directed link is assigned 

sub-networks 12a, 12b, 12c, which provide an extension of an LLID by the head of the link, and the LLID of a link is 

the Internet 14 through a number of Internet Radios or IRs 45 communicated in every link state update for that link. Still 

16a-16/'. Each IR 16a-16z is a wireless router with an another example of a routing protocol that can be used in 

assigned IP address and a MAC address. In general, IRs combination with the present invention is a modification of 

16a-16i operate over one or a multiplicity of radio channels a path-vector protocol (e.g., BGP) such that the paths from 

using spread-spectrum wireless communication techniques source to destinations are specified in terms of both the 

common in the art. For example, the IRs 16a-16i may 50 routers used in the paths, as well as the LLIDs of the links 

operate in one of the unregulated UHF frequency bands, in the same paths; the LLID of a link in a path is given by 

thereby obviating the need for operating licenses. Coupling the head of that link. 

of ad hoc network 10 to the Internet 14 is achieved through The routing protocol assumed for the operation of the 

a router 18, which may be operated by an Internet Service present scheme also provides a routing table with the 

Provider (ISP). As shown, a single ISP may operate a LAN 55 distance and next hop to each destination. The source routes 

20 to which multiple IRs are connected. In such a scheme, needed by a router can be computed on demand by the 

IRs 16a and 166 may act as "AirHeads", providing gateway source of a packet that is to be source switched to the 

service to Internet 14 via router 18. Some IRs, e.g., IRs 16d destination. Alternatively, the routing table may also include 

and X6e of FIG. 1, may be associated with hosts, 22a, 22b the source route specified in terms of LLIDs for each 

and 22c, which can be accessed by any Internet user through 60 destination. Multiple routing entries for the same destination 

ad hoc network 10. Like any router, each IR 16a-16* may be provided, i.e., up to one entry per neighbor per 

processes all messages, changes in the cost of an adjacent destination, and one or multiple routing entries may be 

link, adjacent -link failures, and new-neighbor notifications provided for each type of service defined in the system, 

one at a time and in the order in which it detects them. The preferred approach for this embodiment would be 

Any IR 16a-16Z in FIG. 1 can consider another IR to be 65 based on its combined use with the Adaptive Internet 

adjacent (we call such an IR a "neighbor") if there is radio Routing (AIR) protocol, simply because of the performance 

connectivity between the two IRs and one IR, e.g., IR 16& improvements derived from AIR compared to the other three 
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alternatives listed above. Nevertheless, in another embodi- which the packet should be dropped to prevent packets from 

ment of the present invention, no routing protocol is remaining in the network indefinitely. The reliability (R) 

assumed for its operation, and routes to destinations speci- field 36 specifies the degree of reliability with which the 

fied in terms of LLIDs may be obtained on demand. In this packet must be successfully forwarded by the router. The 

case, a router that originates a packet for a destination and 5 priority (P) field 38 specifies the priority that the packet 

has no routing information for that destination may send shouId be assigned in the transmission queues of the router, 

search packets to its neighbors in order to find an intended Th e P a y loa c d lv If ^OAD) field 40 is optional and specifies 

destination. The search packet sent to a given neighbor the . tv Pf ° f P^yload that follows the header; if the field is 

specifies: the address of the intended destination, the address om * Ue fi d < he « a 1 ssum « 1 to J* * P a ? k * ^ ] 

*1 , - . , , . c .i_ , , j . predefined MAC protocol, such as the REALM protocol 

of the intended recover of the packet, and a source route. 10 ^ ^ * applicatioD Ser . No. 09/248,738, 

The source route of the packet is specified in terms of the emided « Ad £ Communication Protocol for Wireless 

address of the source router and the LLID assigned by the Networks" 

source router to the link with its neighbor. A router receiving ^ rouUng operation code (ROC) 42 specifies the 
a search packet that does not have a routing entry for the instruction (e.g., in binary code format) to be used on the 
intended destination forwards the packet to each of its 15 pac ket, i.e., how the packet should be processed. The value 
neighbors other than the one from which the packet is specified in the ROC field 42 determines which other fields 
received, and the packet specifies: the address of the should be present in the header 30. The routing and switch- 
intended destination, the address of the intended receiver of ing modes include but are not limited to: basic broadcast 
the packet, and a source route with the LLID of the link from mode (ROC=0), hop -by-hop mode (ROC=l), label swap- 
the sending router to the intended receiver added. A router 20 ping mode (ROC=2), source switching mode(ROC«3), flow 
receiving the search packet that has a source route (specified switching mode (ROC=4), source-switched flow establish- 
in terms of LLIDs of the links in the path to the destination) ment (ROC=5), and incremental flow establishment (ROC= 
sends a reply with the entire source route consisting of the 6). 

source router address and the sequence of LLIDs for all the The transmitter's MAC address (XADD) field 44 identi- 

links in the path to the destination. 25 fies the sender of the packet and should always be present in 

II. Information Contained in Packet Headers a packet header 30. The receiver's MAC address (RADD) 

In the present scheme, the header of a packet specifies a field 46 is optional and identifies the receiver of the packet; 

switching or routing instruction that instructs the router to the RADD is present in the header when the ROC specifies 

process the packet in one of multiple possible switching or a routing or switching mode based on the sender and 

routing modes, and specifies the additional information 30 receiver MAC addresses; examples of these modes are 

needed for the router to carry out the operation. In an IP normal packet routing and tag switching, 

internetwork or an ad hoc network extending the IP Internet, The transmitter-assigned link identifier (XLID) field 48 is 

the flow switching protocol of the present invention could be optional and is present when the ROC specifies a forwarding 

used to carry IP packets or it could be used to carry operation in terms of the LLID of the link to the next hop for 

MAC-layer packets that in turn encapsulate IP packets. For 35 the packet. The XLID specifies the local link identifier 

purposes of clarity, we omit the description of conventional assigned by the transmitter to the link with one of its 

framing and error detection functionalities that may also be neighbors. A router cannot assign the same XLID to more 

present in the packet header, and describe the operation of than one link with a neighbor, 

the flow switching protocol in general terms applicable to The receiver-assigned link identifier (RUD) field 50 is 
the forwarding of IP packets and MAC-layer packets. 40 optional and specifies the local link identifier assigned by the 
FIG. 2 presents a canonical packet-header format, which intended receiver of the packet to the link with the trans- 
illustrates the type of routing and switching information mitting router. An RLID reported by router x in a packet 
used in one embodiment of the present scheme, as well as destined for neighbor y is, therefore, the XLID that x knows 
the combination of the various types of information. Various y has assigned to the link (y, x). The RLID field 50 is present 
fields in the canonical packet header 30 can be required 45 in the packet header 30 when the ROC specifies the source 
fields or optional fields. Some of the innovative features of switch or flow switch mode and the lookup at the receiver is 
canonical packet header 30 stem from the use in various accomplished based on receiver-assigned link identifiers, 
combinations of switching and routing instructions, local When RLIDs are used in packet headers, a router accepts the 
link identifiers, source routes specified with local link packet based on the XADD, XLID, and RLID fields, 44, 48 
identifiers, and other forwarding labels, to enable different 50 and 50, of the header. 

routing and switching operations on data packets within the The flow label (FL) field 52 is optional and is present 

same unifying packet processing framework. when the ROC specifies the flow switching mode. The FL 

The canonical packet header description shown in FIG. 2 specifies the label assigned to a flow of packets by the 

omits framing and error checking fields that may be present transmitting router. To minimize the number of flow labels 

in an actual implementation. It should be evident to those of 55 routers have to remember, it may be assumed that a router 

ordinary skill in the an that, depending on a variety of assigns the same flow label to packets of the same traffic 

implementation issues (e.g., bandwidth available in the class flowing to the same destination, 

communication links) this canonical format can be imple- The source route field 54 is optional and is present when 

mented in a variety of ways, ranging from the number of bits the ROC specifies any forwarding operation involving 

used in each field and the the position of the fields in the 60 source switching. It may include three sub- fields (not shown 

packet header, to the use of extension headers in order to in detail), a hop count (HC) specifying the number of entries 

simplify the processing of the most commonly transmitted in the source route, a pointer to the next hop (PNH) 

types of packets. In addition, the canonical packet header 30 indicating the XLID that the receiving router should read to 

described herein can be part of a larger packet header. forward the packet, and a source route (SR) consisting of 

Aversion (V) field 32 specifies the version of the protocol 65 one or more XLIDs. 

to be used to process the packet. The time to live (TI L) field The path-traversed field 56 is optional and is present when 

34 specifies an upper bound in terms of hops or time, beyond the ROC specifies hop-by-hop flow establishment. It 
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includes of a hop count specifying the number of routers 
visited by the packet, and the ordered sequence of MAC 
addresses of the routers visited. 
III. Switching Information Maintained at Routers 

The switching information maintained at routers is used to 5 
switch packets below the IP layer. As will be apparent to 
those of ordinary skill in the art from the subsequent 
description, the introduction of XLIDs and RUDs in the 
present scheme reduces the amount of bandwidth consumed 
by packet headers and, more importantly, enables the imple- 10 
mentation of flow and source switching modes in simple 
hardware. This makes packet switching according to the 
present invention much faster than routing packets by table 
lookups, even if the fast table lookup technology of prior 

schemes is utilized. 15 

^^•sho\y 1 i^#I^ 

^ofswitcfiing tables: a neighbor identification table (NIT) 62, 
a source switching table (SST) 64 and a flow switching table 
(FST) 66 for each neighbor. The NIT 62cpermitsa;touter:to 

ffetermih"e~if a rea^iv^packetis : mtended-for-m^aTrouter anll^ 
if so, which switching table to use to<foWard"jtheipacket. The 
SST 64 specifies the forwarding instructions a router should 
follow to forward packets in source switching mode. Each 
FST 66 specifies the mapping from a g iven incoming .flow 
label to the outgoing flow jabel, the^ eWss^y^LLIDs to 
identifyjLK^ 

tiolrfor the transmission^^ hop. 

^low are presented two exampies^forlhe maintenance of 
switching information in the present routing scheme, which 
embodiments differ depending upon whether or not receiver- 
assigned LLIDs are used for source switching or flow 
switching. 

IIU, Information Stored for Switching 
A. Using Transmitter-assigned LLIDs 

In one embodiment of the present scheme, only 
transmitter-assigned LLIDs are used to identify links 
between neighbors. In this case, the RLID field 50 is not 
used for flow switching or source switching, and the NIT 62 
is indexed according to links incident into the router and 
provides pointers to the SST 64 and the FST 66 as needed. 

More specifically, the keys for the NIT are the XLIDs 
reported by the neighbors of the receiving router for their 
links to that router. One or more neighbors of the subject 
router may use the same XLID value 48 to label their links 
to the router. Accordingly, as shown in FIG. 4, the entry 68 
in the NIT 62 is an array consisting of zero or more array 
entries, each array entry corresponding to a neighbor that 
uses the value of the XLID for a link to the router and 
including: (a) the MAC address of the neighbor and (b) a 
pointer to the FST of the neighbor. In one embodiment, a 
router has relatively few neighbors (e.g., up to 64 neighbors) 
and searching on the XLID as the key is, consequently, very 
fast. Furthermore, if a router has N neighbors, the total 
number of array entries in the NIT 62 is N; hence, in the 
worst case a router has to search in a list of up to N entries 
(either all its neighbors use different XLIDs for their links to 
the router, or all its neighbors use the same value of XLID 
for their links to the router). 

FIG. 5 shows an example network consisting of six 
routers (A-F) connected by point-to-point links. Circles 
indicate routers and lines indicate the links between them. 
The label inside a circle indicates the MAC address of the 
router, and the arrows and labels next to the links connecting 
the routers indicate the XLIDs assigned by a router to each 
link with a neighbor. For example, router A assigns XLID=4 
to its link with router E. Note that no router assigns the same 
XLID to more than one link, and that multiple neighbor 
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routers may use the same XLID for the same router. For 
example, routers B and D assign XLID«1 for their links with 
router A, and routers A and B assign XLID=2 for their links 
with router D. 

Continuing with the same example network FIG. 6 shows 
the NIT 62 A at router A of FIG. 5. Note that the index values 
used in the NIT 62A are those assigned by router A*s 
neighbors to the finks incident into router A, not XLID 
values assigned by router A to links outgoing from router A 
to its neighbors. In the present example, router A has two 
neighbors, routers B and D, using the same value of XUD=1 
to refer to links incident into router A. This is not a problem 
due to the array structure of NIT 62 A, which specifies the 
MAC address of each neighbor of router A using a given 
XLID to denote an incident link into router A and a pointer 
to the proper FST, which is to be used to process packets in 
flow switching mode. Note also that the NIT 62A of router 
A has only four table entries, corresponding to four neigh- 
bors (B, D, C, and E). 
20 Because a source route in a packet header specifies the 
next hop to which the receiving node should forward the 
packet, an SST 64 is indexed on the XLID values that the 
router assigns to its outgoing links with neighbors. Each 
entry in an SST 64 specifies an outgoing interface and 
25 link-level information for the transmission of the packet to 
the next hop. Continuing with the same example network of 
FIG. 5, FIG. 7 shows the SST 64A at router A; the MAC 
addresses of neighbor routers are shown in parenthesis since 
they are not stored in the SST. Note that the four entries 
30 indexed by XLID value correspond to the four finks going 
from router A to its neighbors. 

As earlier stated, a router maintains a flow switching table 
(FST) 66 for each neighbor router. /The FST for a given 
neighbor is indexed according to the values of the incoming 
35 flow labels used for flow switching. For a given value of an 
incoming flow label, the FST specifies the value of the 
outgoing flow label, link-level information for the transmis- 
sion of the packet to the next hop, and the value of the XLID 
to be used when a packet is forwarded to the next hop in flow 
40 switching mode. The use of the latter entry is unique in the 
present scheme relative to all prior packet switching tech- 
niques based on label swapping. 

Using the same example network of FIG. 5, FIG. 8 shows 
the FST 66A at router A for its neighbor router D. It is 
45 assumed that two flows going from D to A have been 
established already. One flow is identified with the incoming 
flow label fll and the other with incoming flow label fl2. For 
fll, the forwarding instruction in the FST 66A specifies that 
router A should swap fll for fix when it forwards a packet for 
so the corresponding flow, and that it should specify XLID=1 
in the packet header and forward the packet to neighbor 
router B. The routing instruction also specifies all the 
necessary link-level information, which is dependent on the 
type of network being used (e.g., an ad hoc network or a 
55 wired network). 

IIL2. Information Stored for Switching Using Receiver- and 
Transmitter-assigned LLIDs 

In an alternative embodiment of the present scheme, 
routers use the receiver- assigned link identifier (RUD) field 
60 50 to identify a given link with the local link identifiers 
assigned by each end of the link. The headers of packets to 
be forwarded according to source switching and flow 
switching specify the RUD in addition to the XLID. 
In this embodiment, the NIT at each router is indexed by 
65 the RLID, i.e., the local link identifier assigned by the router 
to its outgoing links, which is specified by a neighbor router 
in the header of the packet. The NIT entry for a given value 
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of the RLID specifies the MAC address of a neighbor, the 
XLID assigned to the link by the router, and a pointer to the 
FST for that neighbor. Continuing with the same example 
network of FIG. 5, we note that any router knows the LLID 
assigned by each of its neighbors to the link from the 5 
neighbor to the router. Router A, for example, knows that 
router E assigned the LLID=3 to the link from E to A. This 
information can be made available to the flow switching 
protocol by different means, including an underlying chan- 
nel access layer and a routing protocol. 10 

FIG. 9 shows the NTT 70A at router Aof FIG. 5. Note that 
the index values used in the NTT 70A are now the RLIDs 
assigned by the subject router to each of its neighbors, and 
all such RLIDs are different from each other. The NIT 70A 
specifies the MAC address of a neighbor, the LLID assigned is 
by the neighbor to the fink with the router, and a pointer to 
the FST used when packets are flow switched. 

A router accepts a packet based on the values of the 
XADD, XUD, and RLID fields, 44, 48 and 50, of the packet 
header. More specifically, the RLID field 50 identifies the 20 
entry of the NIT that should be further examined, if no entry 
of the NIT is labeled with a value equal to the RLID of the 
packet, the packet is discarded. If the XADD and XLID do 
not correspond to the MAC and LLID values of the NIT 
entry specified by the RLID value, the packet is discarded. 25 

The SST is indexed on the XLID values that the subject 
router assigns to its outgoing links with neighbors. Each 
entry in the SST specifies the LLID assigned to the link by 
the neighbor router (RLID to be used in a packet header), 
outgoing interface, and link-level information for the trans- 30 
mission of the packet to the next hop. Continuing with the 
same example network of FIG. 5, FIG. 10 shows the SST 
72A at router A. 

The FST for a given neighbor specifies, for a given value 
of an incoming flow label, the value of the outgoing flow 35 
label, link- level information for the transmission of the 
packet to the next hop, and the value of the XLID and RLID 
to be used when a packet is forwarded to the next hop in flow 
switching mode. Using the same example network of FIG. 
5, FIG. 11 shows the FST 74A at router A for its neighbor 40 
router D. It is assumed that two flows going from D to A 
have been established already. One flow is identified with 
the incoming flow label fll and the other with incoming flow 
label fl2. For fll, the forwarding instruction in the FST 74A 
specifies that router A should swap fll for fix when it 45 
forwards a packet for the corresponding flow, and that it 
should specify XLID=1 in the packet header and forward the 
packet to neighbor router B. 
IV. Packet Forwarding Modes 

We now describe how the present scheme supports a 50 
number of routing and switching modes of packet forward- 
ing operations based on the information specified in packet 
headers and routing and switching information maintained at 
routers. The overall handling of packets by the present flow 
switching protocol can be described, by the following 55 
pseudo-code. 

Procedure Process-Packet 

{called by packet arriving at router} 

do CASE 60 
ROC=0: call Broadcasting 
ROC=l: call Hop_by_Hop 
ROC-2: call Label_Swapping 

ROO=3: call Source_Switching 65 
ROC«4: call FIow_Switching 
ROC-5: call Source_Switched__Flow 



ROC-6: call Increment al_Flow 
ROC=7: call Incremental_S witching 
End Process-Packet 

In the following, we describe each packet forwarding mode 

used to process packets. This description considers the two 

alternative embodiments discussed above. 

IV. 1. Basic Broadcasting and Conventional Point-to-Point 

Transmissions 

A router sends a packet with a header specifying ROC=0 
to force all its neighbors process the packet and pass it to a 
higher layer, where additional processing takes place. A 
router receiving a packet with its header specifying ROC=0 
simply accepts the packet and passes it to the higher layer. 
This packet-forwarding mode could be used to support 
network-layer control functions requiring routers to com- 
municate with all their neighbors. 

The point-to-point mode is used to simply pass informa- 
tion from one router to one of its neighbors or to a subset of 
its neighbors using a multicast MAC address. In this case, 
the header of the packet specifies ROC=l and includes the 
RADD field 46. A router that receives the packet with 
ROC=l accepts the packet if the RADD in the packet header 
equals the router's own MAC address or a multicast MAC 
address to which the router belongs. In such a case, the 
accepted packet can be routed at the higher layer (e.g., the 
IP layer) using a standard routing table based on destination 
addresses. The final destination of the packet or a conven- 
tional source route should be included in the payload that 
follows the packet header, just as is the case for IP packets 
encapsulated in frames that are formatted according to IEEE 
Standard 802.3. 

IV.2. Conventional Label Swapping 

In the label-swapping mode, the header of a packet 
specifies ROG=2 and includes the RADD and FL fields 46 
and 52. Packets are switched to their destinations in much 
the same way as in other protocols based on local VC 
identifiers. A router accepts a packet based on the RADD in 
the header, and the accepted packet is forwarded by swap- 
ping the incoming flow label in the header with the outgoing 
flow label stored in a flow switching table stored at the router 
and indexed by the incoming flow label and the MAC 
address of the neighbors of the router. In this mode of 
operation, the difference between the present scheme and 
earlier ones stems from the way in which routers can 
establish the label swapping state using source switching. 
IV.3. Source Switching 

The source switching mode is unique to the present 
scheme. In source switching mode, the router that originates 
the packet first obtains the source route to the intended 
destination in terms of the LLIDs assigned to the links along 
the path from source to destination. As earlier established, 
the router obtains this information either through the routing 
protocol used in combination with this routing scheme, or by 
means of control search packets disseminated in the net- 
work. 

Once a router has a source route based on LLIDs to the 
intended destination, it forwards a packet specifying the 
source-switching mode (ROC=3) to the next-hop router 
along the source route to the destination. The header of such 
a packet also contains the XLID assigned by the router to the 
link with the next hop of the source route, the router's own 
MAC address, the source route to the destination specified 
as a sequence of XLIDs, and a pointer into the source route 
informing its neighbor which is the next hop that the 
neighbor should examine. If receiver-assigned LLIDs are 
used, the header also contains the RUD assigned by the 
intended receiver to the link with the router sending the 
packet. 
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A packet is source switched at every hop by reading the 
source route in the packet header and substituting the XLID, 
and if present the RLID, specified in the header to allow the 
router to accept the packet with the XUD, and RLID if 
present, needed by the next hop. 

Note that although LLIDs are swapped at each router, the 
labels used in source switching are very different than those 
used in the label switching approaches of the past, because 
they refer to the links over which the packet must flow, 
rather than the destination, or association from source to 
destination, for which the packet is intended. 

Another approach to source switching would consist of 
specifying the MAC address of the next hop in the source 
route along with the source route specified in terms of 
LUDs. Such a variation of the source switching approach 
could be used when channel bandwidth is not at a premium. 
The packet header in this forwarding mode would specify 
the source route field and would substitute the XLID field 48 
for the RADD field 46. A router can then accept a packet 
based on the MAC address of the intended receiver specified 
in the header. However, given that LLIDs have to be used to 
provide a simple index to the SST, there may be little or no 
advantage to using the MAC address of the receiver rather 
than the LLID of the link to the same router. 
IV.3.a. Source Switching Using Receiver- and Transmitter- 
assigned LLIDs 

The switching operation at a router when receiver- 
assigned LLIDs are used in packet headers consists of 
accepting the packet and forwarding the packet, if accepted. 
The following pseudo-code specifies the procedure formally, 
which operations can be implemented in hardware or soft- 
ware. 

First, the router decides whether to accept the packet or 
not based on the XADD, XLID, and RLID fields, 44, 48 and 
50, of the packet header, which must match with one entry 
in the NTT 62 of the router. The XADD and XLID identify 
the link from neighbor to router; however, to permit the 
router receiving the packet to scan its NIT 62 using a simple 
index, the RLID given to the link from the router to the 
neighbor is also included in the packet. Accordingly, the 
router can scan its NIT 62 using the received RLID as the 
key, and decide whether or not to accept the packet by 
matching the XADD and XLID from the packet with the 
MAC address and LLID stored in its NIT 62. 

If the packet is accepted, the router scans its SST 64 based 
on the XLID of the packet. To forward the packet to the next 
hop, it advances the PNH of the source route field 54 of the 
packet, and substitutes the XLID and RLID received with 
those expected by the next hop. The packet is then forwarded 
according to the link-level information for the next hop 
maintained in the SST 64. 

The key advantage of this approach to source switching is 
that the look up in the NIT 62 is based on a simple key, and 
the added overhead of including the receiver-assigned LLID 
of a link (RLID) is minimal, because a router has a relatively 
small number of neighbors, which means that the lengths of 
the XLID and RUD fields 48 and 50 are small. 
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-continued 



XADD: Transmitter's MAC address specified in packet header. 

NIT. did: Any LLID in NET assigned by router to a link 

with a neighbor. 
NTT(RLID): Row of the NTT specified by RLID. 

NTT(RlJD).mac: MAC address stored in NIT entry specified by RLID 

value. 

NIT(RLID)j£lid: LLID assigned by neighbor to link with router 

and stored in NTT entry specified by RLID value. 
PNH(SR): Local link identifier specified by the pointer 

to the next hop (PNH) in packet header. 
SST.xlid: Any local link identifier in SST 

assigned to an outgoing link. 
SST(XLID).rlid: LUD assigned by neighbor to its link with router 

and stored in SST entry specified by XLID value. 
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Procedure Source„S witching 

{called when packet with R0O3 is received} 

1. If (XADD ! =NTT(RLID).mac or XLID!-NIT(RLID) 
.xlid) then reject packet and return 

2. If (PNH(SR)!=SST.xlid) then reject packet and return 

3. XLID<-PNH(SR) 

4. RLID<-SST(XLID).rlid 

5. PNH<-PNH+1 

6. Forward packet according to forwarding instructions 
for SST(XLID) 

End Source_Switching 

IV.3.6. Source Switching Using Transmitter- Assigned Local 
Link Identifiers 

A router receiving a packet specifying source switching 
may process the packet using the simple procedure specified 
in pseudo-code below. First, the router decides whether to 
accept the packet or not based on the XADD and XLID 
fields, 44 and 48, of the packet header, which must match 
with one array entry 68 in its NIT 62. The XLID and XADD 
uniquely identify a receiver router, because MAC addresses 
are unique and no router assigns the same XLID to more 
than one neighbor. Furthermore, searching the NIT 62 for a 
match between the packet's XLID and a LLID assigned to 
the router by one of its neighbors is very fast, because the 
router can have no more LLIDs assigned to it than the 
neighbors it has, and given a match with the packet's XLID 
searching for a match between the packet's XADD and the 
MAC addresses of the neighbors that assigned the same 
LLID to the router is very fast, because only a subset of the 
router's neighbors can use the same LLID for their links to 
the router. 

If the packet is accepted, the router scans its SST 64 based 
on the XLID of the packet. To forward the packet, the router 
substitutes the XLID with the LLID corresponding to the 
PNH value of the source route and increments the PNH of 
the packet header. The packet is then forwarded according to 
the link-level information maintained in the SST 64 for the 
next hop in the route. The following pseudo-code formally 
specifies this simple procedure. 



SR: Source route specified in packet header. 

NTT: Neighbor identification table. 

SST: Source switching table. 

XLID: Transmitter-assigned link identifier specified in 

packet header. 

RLID: Receiver-assigned link identifier specified in 

packet header. 



SR: Source route specified in packet header. 

PNH(SR): Local link identifier specified by the pointer to the next 

hop (PNH) in packet header. 

NIT: Neighbor identification table. 

SST: Source switching table. 

XUD: Transmitter-assigned link identifier specified in packet 

65 header. 

XADD: Transmitter's MAC address specified in packet header. 
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-continued 



NTLxlid: Any LLID in NTT assigned by a neighbor to the link 

with the router. 
N1T(XLID): Row of the NTT specified by XUD. 
SST(XUD): Row of the SST specified by XLID. 
NTTfXU D). mac: Any MAC address in the row of the NTT specified by 

XUD. 

SSTjtlid: Any local link identifier in SST assigned to an 

outgoing link. 



Procedure Source_Switching 

{called when packet with R0O3 is received} 

1. If (XLID!=NIT.xlid) then reject packet and return 

2. NIT(x)<-l 

3. found<-false 

4. While not (found) do 
found<-NIT(x).mac and XADD 
NIT(x)<-NIT(x)+l 

5. If (not found) then reject packet and return 

6. If (PNH(SR)!=SST.xlid) then reject packet and return 

7. XUD<-PNH(SR) 

8. PNH<-PNH+1 

9. Forward packet according to forwarding instructions 
for SST(XUD) 

End Source_Switching 



FST_p(lFL): Forwarding instruction in FST_p for incoming flow 

label specified by IFL. 
5 FST__p.ifl: Any incoming flow label in FST_p. 

FST_p(FL).ofl: Outgoing flow label in the entry for incoming flow 

label FL in FST_p. 
FST_4)(FL)jdid: LUD assigned by router to link with neighbor and 

stored in FST_p entry specified by FL 
FST_p(FL).rlid: LUD assigned by neighbor to link with router and 
10 stored in FST_p entry specified by FL. 

NIT(RLID).mac: MAC address stored in NTT entry specified by RUD. 
NTT(RLID)jElid: LLID assigned by neighbor to link with the router in 

NIT entry specified by RLID. 
NTT(RlID).ptn Pointer to an FST in NTT entry specified by RLID. 



FST__p: The flow switching table specified 

by the pointer p. 

XLID: Transmitter-assigned link identifier specified in 

packet header. 

RUD: receiver-assigned link identifier specified in 

packet header. 

FL: Flow label specified in packet header. 
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The above procedure can also be implemented in hardware 30 
or software. 
IV.4. Flow Switching 

The flow switching mode is unique to the present scheme 
and provides for packet switching using label swapping 
without the need to specify the MAC address of the receiver 
of the packet. This is accomplished by using the same 
approach used for source switching to determine when a 
packet should be accepted. If a match is found in the NIT 62 
for the tuple formed by the XLID and XADD of the packet, 
or for the tuple formed by RLID, XLID, and XADD, if 
receiver-assigned LLIDs are used, the NIT 62 provides a 
pointer to the flow switching table (FST) 66 maintained for 
the neighbor that sent the packet. 

The FST 66 maintains the mapping between the flow label 
specified in the packet and the flow label to be used for the 
next hop, together with the LLID of the link to the next hop 
and any outgoing link-level information. If RLIDs are used 
in packet headers, the FST 66 also specifies the RLID to be 
included in the header of the outgoing packet. 

To forward a received packet, the subject router substi- 
tutes in the outgoing packet the values of either FL and 
XLID, or FL, XLID, and RLID in the header of the received 
packet with the entries specified in the FST 66 for the next 
hop of the packet. The following pseudo-code specifies the 
procedure used for flow switching when RLIDs are included 
in packet headers. 
NIT: Neighbor Identification Table 



Procedure Flow_Switching 

{called when packet with ROC=4 is received} 

1. If (XADD!«NIT(RLID).mac or XLID!«NIT(RLID) 
.xlid) then reject packet and return 

2. p<-NIT(RUD).ptr 

3. If (FL!=FST_jxifl) then reject packet and return 

4. IFL<-FL 

5. XLID<-FST_p(FL).xlid 

6. RLID<-FST_p(FL).rlid 

7. FL<-FST_p(FL).ofl 

8. Forward packet according to forwarding instructions 
for FST_p(IFL) 

End FIow_Switching 

The following pseudo-code specifies the procedure used for 
flow switching when no RLIDs are used in packet headers. 
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NTT: Neighbor identification table. 

FST_p: The flow switching table specified by the 

pointer p. 

XLID: Transmitter-assigned link identifier specified in 

packet header. 

FL: Flow label specified in packet header. 

XADD: Transmitter's MAC address specified in packet 

header. 

NIT.xlid: Any LUD in NIT assigned by a neighbor to the 

link with the router. 
NIT(XUD): Row of the NIT specified by XUD. 

NIT(XUD).mac: Any MAC address in the row of the NIT 

specified by XLID. 
FST_p.ifl: Any incoming flow label in FST_p. 

FST_p(FL).ofl: Outgoing flow label in the entry for incoming 

flow label FL in FST_p. 
FST_p(FL).xlid: LLID in the entry for incoming flow label FL 

in FST_p. 

NTTpQJD,XADD).ptr: Pointer to an FST for neighbor with MAC 
address that matches XADD in NTT entry 
specified by XLID. 
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Procedure Flo w_S witching 

{called when packet with R0O4 is received} 

1. If (XLID!=NITxlid) then reject packet and return 

2. NTT(x)<-l 

3. found<-false 

4. While not (found) do 
found<-NIT(x).mac and XADD 
NTT(x)<-Nrr(x)+l 

5. If (not found) then reject packet and return 

6. p<-NIT(XLID,XADD).ptr 

7. If (FL!=FST__p.ifl) then reject packet and return 
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8. FL<-FL 

9. XUD<-FST_p(FL).xlid 

10. FL<-FST_p(FL).ofl 

11. Forward packet according to forwarding instructions 
for FST(IFL) 

End Flow_Switching 

IV.5. Incremental Switching 

With incremental switching, a packet is accepted by a 
router based on the XADD, XUD, and RUD specified in the 
header using the same approach described for source switch- 
ing. The accepted packet is then passed to a higher layer for 
further processing, which may include routing at the net- 
work layer. 

V Establishing Flow State at Routers 

In the present scheme, flow state may be established either 
incrementally or using source routes, and establishing flow 
state amounts to another packet forwarding mode, i.e., flow 
state is established by forwarding data packets. A router that 
decides to establish flow state along a loop-free path to a 
destination first obtains the source route to the destination in 
the same way as in source switching mode. Once the router 
obtains a source route, it sends a source-switched data 
packet with flow setup instructions, so that flow state can be 
set as the packet traverses the source route to the destination. 
The header of the packet specifies: the source-switched flow 
establishment operation code (ROC=5), the MAC address of 
the transmitting router (XADD), the XUD of the link to the 
next hop, a flow label (FL), and the source route field 54. 

When a router receives a packet with the source-switched 
flow establishment operation code, it establishes flow state 
and forwards the packet according to source switching. The 
router determines whether to accept the packet or not based 
on the XADD, XUD, and RLID fields, 44, 48 and 50, of the 
header, or the XADD an XLID fields, 44 and 48, only, if no 
RLIDs are used to implement source switching and flow 
switching. If the packet is accepted, the receiving router 
establishes an entry in the FST 66 for its neighbor; in such 
an entry the FL received in the packet is mapped into an 
outgoing flow label created by the router and the XLID and, 
if applicable, the RLID of the next hop in the source route 
specified in the packet. The router forwards the packet as in 
the case of source-switching mode, together with the swap- 
ping of flow labels. 

The following pseudo-code describes the procedure used 
when RLIDs are used in packet headers in the present 
scheme. 



SR: 
NTT: 
SST: 
XLID: 

RUD: 

XADD: 
NTT. did: 

NTT(RLID): 
SST(XLID): 
NTT(RLID).rnac: 

NTT(RUD).xlid: 

PNH(SR): 
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Source route specified in packet header. 
Neighbor identification table. 
Source switching table. 

Transmitter-assigned link identifier specified in packet 
header. 

Receiver-assigned link identifier specified in packet 
header. 

Transmitter's MAC address specified in packet header. 
Any LLID in NTT assigned by router to a link with a 
neighbor. 

Row of the NTT specified by RLID. 

Row of the SST specified by XLID. 

MAC address stored in NTT entry specified by RLID 

value. 

LLID assigned by neighbor to link with router and 
stored in NTT entry specified by RLID value. 
Local link identifier specified by the pointer to the next 
hop (PNH) in packet header. 
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SSTjttid: Any local link identifier in SST assigned to an 

outgoing link. 

SST(XUD).rlid: LLID assigned by neighbor to its link with router and 
stored in SST entry specified by XLID value. 



Procedure Source_Switched_Flow 

{called when packet with R0O3 is received} 

1. If (XADD!=NIT(RLID).mac or XLID NIT(RLID) 
.xlid) then reject packet and return 

2. If (PNH(SR)!=SST.xlid) then reject packet and return 

3. p<-NIT(RLID).ptr 

4. Create new entry in FST_p for FL 

5. XLID<-PNH(SR) 

6. RLID<-SST(XLID).rlid 

7. PNH<-PNH+1 

8. Forward packet according to forwarding instructions 
for SST(XLID) 

End Source_Switched_Flow 



The following pseudo-code specifies the procedure used 
to establish flow state with source switching when RLIDs 
are not used in packet headers. 



30 

SR: 

PNH(SR): 

NIT: 
SST: 
35 XUD: 

XADD: 

FL: 

NTTpCLID): 
40 NIT(XLID).mac: 

SSTxlid: 

NIT(XUD,XADD).ptr: 
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FST_p(FL).ofl: 
FST_p(FL)jclid: 



Source route specified in packet header. 
Local link identifier specified by the pointer to 
the next hop (PNH) in packet header. 
Neighbor identification table. 
Source switching table. 

Transmitter-assigned link identifier specified in 
packet header. 

Transmitter's MAC address specified in packet 
header. 

Flow label specified in packet header. 
Row of the NTT specified by XLID. 
Any MAC address in the row of the NIT 
specified by XLID. 

Any local link identifier in SST assigned to an 
outgoing link. 

Pointer to an FST for neighbor with MAC 
address that matches XADD in NTT row given 
by XLID. 

Outgoing flow label in the entry for incoming 
flow label FL in FST_p. 
LLID in the entry for incoming flow label FL 
in FST_p. 
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Procedure Source_Switched_Flow 

{called when packet with ROC=5 is received} 
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If (XLID!=NlT.xlid) then reject packet and return 

NlT(x)<-l 

found<-false 

While not (found) do 

found<-NIT(x).mac and XADD 

NTT(X)<-NIT(x)+l 

If (not found) then reject packet and return 

If (PNH(SR)!-SST.xlid) then reject packet and return 

p<-NTT(XLID,XADD).ptr 

Create new entry in FST_p for FL 

8.a. FST_p(FL).ofl<-new ofi for FST__p 

S.b. FST_4>(FL).xlid<-PNH(SR) 

XLID<-PNH(SR) 
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10. PNH<-PNH+1 

11. FL<-FST_p(FL).ofl 

12. Forward packet according to forwarding instructions 
for SST(XLID) 

End Source_Switched__Flow 

If the present scheme is used in combination with a 
routing protocol, flow state can also be established incre- 
mentally. In this case, the router obtains the next hop to a 
destination from its routing table and forwards a data packet 
with the following control information in its header: the 
ROC=6, the MAC address of the router (XADD), the XLID 
of the link to the next hop, a flow label (FL), and the 
path-traversed field 56. The path-traversed field 56 specifies 
the path traversed by the packet from its origin to the present 
hop in terms of the MAC addresses of each hop visited by 
the packet. 

A router that receives the packet with ROC«=6 accepts it 
based on the XLID, XADD tuple. The router then deter- 
mines if the packet has visited the router before and, if so, 
discards the packet. If no such loop is detected, the router 
then consults its routing table and obtains the LLID for the 
link to its next hop to the intended destination. Note that the 
address of the destination is specified in the payload of the 
packet, not in its header. Once the next hop and the LLID for 
the next hop are obtained, the router installs the mapping 
between the FL (incoming flow label) of the received packet 
and a new outgoing flow label and the LLID for the next hop 
towards the destination (obtained from its routing table). The 
router then substitutes FL with its outgoing flow label for the 
destination, adds its MAC address to the path-traversed field 
56, and sends the packet to the next hop. Thus, although such 
an approach is viable, the preferred approach to flow setup 
is source -routed flow setup, because it incurs much less 
communication and processing overhead. 

Thus, a scheme for routing and switching in computer 
networks has been described. Although discussed with ref- 
erence to certain illustrated embodiments, however, the 
more general applicability of the following claims should 
not be limited thereby. 

What is claimed is: 

1. A method comprising: 

receiving a packet at a first router of a data network; 

forwarding the packet to a second router of the data 
network according to one of a plurality of forwarding 
modes specified by a routing operation code in the 
header of the packet, wherein the plurality of modes 
comprise (1) modes wherein the packet is accepted 
based on a receiving node address included in the 
header and (2) source switching, flow switching, and 
incremental modes wherein the packet is accepted 
based at least in part on a local link identifier included 
in the header. 

2. The method of claim 1, wherein the plurality of modes 
further comprise a broadcast mode wherein packets trans- 
mitted by the first router are accepted by all neighboring 
routers of the first router. 

3. The method of claim 1, wherein the modes wherein a 
packet is accepted based on a receiving node address 
included in the header comprise a label swapping mode and 
a hop-by-hop mode wherein the packet is accepted based on 
the receiving node address included in the header. 

4. The method of claim 1, wherein a value of the routing 
operation code determines certain types of other information 
included in the header of the packet. 

5. The method of claim 4, wherein a sending node address 
is included in the header of the packet regardless of which 
of plurality of modes is specified by the routing operation 
code. 
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6. The method of claim 5, wherein the sending node 
address comprises a medium access code address of the 
sending node. 

7. The method of claim 4, wherein the receiving node 
5 address comprises a medium access code address of the 

receiving node. 

8. The method of claim 2, wherein the header of the 
packet includes a receiving node-assigned local link identi- 
fier if the routing operation code specifies one of the source 

10 switching or flow switching modes. 

9. The method of claim 1, wherein the header of the 
packet includes a flow label if the routing operation code 
specifies the flow switching mode. 

10. The method of claim 1, wherein the flow switching 
is mode receiving routers are identified using local link iden- 
tifiers associated with communication links between trans- 
mitting routers and intended receiving routers. 

11. The method of claim 1, wherein in the flow switching 
mode, flow states at routers of the data network are estab- 

20 lished according to information in data packets transmitted 
within the data network. 

12. The method of claim 11, wherein the information 
included in the data packets allows for bindings between 
incoming and outgoing flow labels to be established at each 

25 of the routers. 

13. The method of claim 1, wherein the header of the 
packet includes a source route to an intended destination if 
the routing operation code specifies the source switching 
mode. 

30 14. The method of claim 13, wherein the source route is 
specified in terms of local link identifiers used by routers in 
the data network. 

15. The method of claim 13 wherein the source route is 
obtained by using either a flood search process or a routing 

35 protocol operative within the data network. 

16. The method of claim 1, wherein forwarding the packet 
comprises: 

reading in the header of the packet at the first router a 
routing operation code that specifies the source switch- 
40 ing mode; 

reading in the header of the packet at the first router a 
source route; 

replacing a first transmitting router local link identifier in 
the header of the packet at the first router with a second 
45 transmitting router local link identifier needed by the 
second router. 

17. The method of claim 1, wherein forwarding the packet 
comprises: 

5Q reading in the header of the packet at the first router a 
routing operation code that specifies the source switch- 
ing mode; 

reading in the header of the packet at the first router a 
source route; 

55 replacing a first transmitting router local link identifier 
and a first receiving router local link identifier in the 
header of the packet at the first router with a second 
transmitting router local link identifier and a second 
receiving router local link identifier needed by the 

60 second router. 

18. The method of claim 1, wherein forwarding the packet 
comprises: 

reading in the header of the packet at the first router a 
routing operation code that specifies the flow switching 
65 mode; 

reading in the header of the packet at the first router a 
source route; 
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replacing a first flow label in the header of the packet at 
the first router with a second flow label needed by the 
second router. 

19. The method of claim 1, wherein the packet comprises 
a data packet that includes flow setup instructions for a next 
receiving node. 

20. The method of claim 1, wherein the header of the 
packet includes a path-traversed field. 

21. The method of claim 3, wherein forwarding the packet 
comprises: 

reading in the header of the packet at the first router a 
routing operation code that specifies the label swapping 
mode; 

replacing a first flow label in the header of the packet at 
the first router with a second flow label by indexing a 
flow switching table stored at the first router. 

22. A packet for use in a data network, comprising: 

a header that includes a routing operation code that 
specifies one of a plurality of modes for forwarding the 
packet within the data network, wherein the plurality of 
modes comprise (1) modes wherein a packet is 
accepted based on a receiving node address included in 
the header and (2) source switching, flow switching, 
and incremental modes wherein a packet is accepted 
based at least in part on a local link identifier included 
in the header and not on a receiving node address; and, 

a payload. 

23. The packet of claim 22, wherein the plurality of modes 
further comprise a broadcast mode. 

24. The packet of claim 22, wherein the modes wherein a 
packet is accepted based on a receiving node address 
included in the header comprise a label swapping mode and 
a hop-by-hop mode wherein the packet is accepted based on 
the receiving node address included in the header. 

25. The packet of claim 22, wherein the header further 
includes a sending node address regardless of which of the 
plurality of modes is specified by the routing operation code. 

26. The packet of claim 25, wherein the sending node 
address comprises a medium access code address of the 
sending node. 

27. The packet of claim 22, wherein the receiving node 
address comprises a medium access code address of the 
receiving node. 

28. The packet of claim 22, wherein the header includes 
a transmitting node-assigned local link identifier if the 
routing operation code specifies one of the source switching, 
flow switching, or incremental modes. 

29. The packet of claim 22, wherein the header includes 
a receiving node — assigned local link identifier if the routing 
operation code specifies one of the source switching or flow 
switching modes. 

30. The packet of claim 22, wherein the header includes 
both a transmitting node-assigned local link identifier and a 
receiving node-assigned local fink identifier if the routing 
operation code specifies one of the source switching, flow 
switching, or incremented modes. 

31. The packet of claim 22, wherein the header includes 
a flow label if the routing operation code specifies the flow 
switching mode. 

32. The packet of claim 22, wherein the packet includes 
a source route to an intended destination if the routing 
operation code specifies the source switching mode. 

33. The packet of claim 22, wherein the header includes 
a path-traversed field. 

34. The packet of claim 33, wherein the path-traversed 
field comprises (1) a hop count specifying a total number of 
routers visited by the packet and (2) an ordered sequence of 
medium access control addresses of routers visited by the 
packet. 
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35. The packet of claim 22, wherein the header includes 
a payload-type field that specifies the type of payload that 
follows the header. 

36. The packet of claim 22, wherein the header includes 
5 a time to live field. 

37. The packet of claim 36, wherein the header further 
includes a version field that specifies a version of a protocol 
used to process the packet. 

38. The packet of claim 37, wherein the header further 
10 includes (1) a reliability field that specifies a degree of 

reliability with which the packet must be successfully for- 
warded by a router and (2) a priority field that specifies a 
priority that the packet should be assigned in a transmission 
queue of a router. 

15 39. The packet of claim 22, wherein the routing operation 
code determines which of a plurality of fields of information 
are included in the header of the packet, wherein the 
plurality of fields of information comprise (1) address infor- 
mation of a receiving router, (2) local link identifier infor- 

20 mation assigned by a transmitting router, (3) local link 
identifier information assigned by a receiving router, (4) a 
flow label, (5) a source route, (6) a path traversed, and (7) 
a payload type. 

40. A router comprising: 

25 a neighbor identification table configured to allow the 
router to determine whether a received packet should 
be accepted and, if so, which of a plurality of switching 
tables to access to retrieve information for forwarding 
the packet within a data network; 

30 a source switching table of the plurality of switching 
tables, wherein the source switching table is configured 
to provide packet forwarding information which the 
router is to use to forward the packet using a source 
switching process; 
a flow switching table of the plurality of switching tables, 
wherein the flow switching table is configured to pro- 
vide packet forwarding information when the router is 
to forward the packet using a flow switching process, 

4Q wherein the flow switching table specifies mappings 
from incoming flows to outgoing flows, local link 
identifiers for next hops, and associated link-level 
information. 

41. The router of claim 40, wherein the neighbor identi- 
45 fication table is arranged so as to be indexed using local link 

identifiers assigned by neighboring routers to links commu- 
nicatively coupling the router thereto. 

42. The router of claim 40, wherein the neighbor identi- 
fication table is further arranged to provide pointers to the 

50 source switching table and the flow switching table. 

43. The router of claim 40, wherein the neighbor identi- 
fication table is arranged so as to be indexed using local link 
identifiers assigned by the router to links to neighboring 
routers. 

55 44. The router of claim 40, wherein the source switching 
table is arranged so as to be indexed according to local link 
identifiers assigned by neighboring routers to links commu- 
nicatively coupling the router thereto. 

45. A router of a data network, comprising: 
60 means for receiving a packet; and, 

means for forwarding the packet to another router of the 
data network according to one of a plurality of for- 
warding modes specified by a routing operation code in 
the header of the packet, wherein the plurality of modes 
65 comprise (1) modes wherein the packet is accepted 
based on a receiving node address included in the 
header and (2) source switching, flow switching, and 
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incremental modes wherein the packet is accepted 
based at least in part on a local link identifier included 
in the header. 

46. The router of claim 45, wherein the plurality of modes 
further comprise a broadcast mode. 

47. The router of claim 45, wherein the modes wherein a 
packet is accepted based on a receiving node address 
included in the header comprise a label swapping mode and 
a hop-by-hop mode wherein the packet is accepted based on 
the receiving node address included in the header. 

48. The router of claim 45, wherein a value of the routing 
operation code determines certain types of other information 
included in the header of the packet. 

49. The router of claim 45, wherein the means for 
forwarding the packet comprise: 



10 



28 



means for reading in the header of the packet a routing 
operation code that specifies the source switching 
mode; 

means for specifying an outgoing interface and link-level 

information for transmitting the packet to a next hop. 
50. The router of claim 45, wherein the means for 
forwarding the packet comprise: 

means for reading in the header of the packet a routing 

operation code the specifies the flow switching mode; 
means for mapping an incoming flow label to an outgoing 

flow label; 
means for identifying a next hop; 
means for specifying necessary link-level information for 

transmitting the packet to the next hop. 
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